雖然有著十多年的troubleshooting經驗，但是客人給了很多個log，跟客人一個log都沒給的這兩種case，在troubleshooting上的難度是非常接近的。

給了很多log的客人，往往自己很有想法，技術能力也不差，但是你要讓他替你執行一些操作時的難度就會變高。因為你的行為或建議必需要有一定的說服力，才能讓他心甘情願配合。

什麼log都沒給的客人，大多都是自己本身也沒有想法，只想著要來跟你求救，就算你只是讓他做一些基本資料的收集，可能都需要特別為他準備一份詳盡的SOP，深怕客人動不動就想讓你參加conference call，一起觀察收集log的過程。

那麼該讓客人收集什麼log呢？還有這些東西要上那找？

下面是我總結一些常見的例子以及相對應的建議：

1. 應用程式的錯誤：

   應用程式通常會擁有自己的一個或是多個log檔，最常見的位置是在自己的安裝目錄下。又或者是像linux中的/var/log資料夾集中管理，也有見過通通往OS的syslog倒的例子。

   windows應用程式比起linux的管理方式我覺得又更難找一些，可能主要是圖形化的程度比較高的原因吧，除了安裝目錄外，也有windows event log viewer需要去做查看，同時還會有預設關閉的log。

   比如說像是Windows的WDS server服務，以往在client端PXE遇到問題時，常常就是拋出一個error code，而後留下滿臉問號的user & admin，就算不然去server的eventlog viewer，翻了老半天後，可能也只看到和截圖一模一樣的錯誤訊息。
   

   在已經能複製問題的前提下，手動的開啟client/server雙邊的應用程式log，才有辦法盡可能的找到線索來調整對應的設定或是排除問題。以下是Microsoft 對WDS server開啟額外log的建議：

   https://learn.microsoft.com/en-us/troubleshoot/windows-server/setup-upgrade-and-drivers/enable-logging-windows-deployment-service

   從上面的連結裡可以發現，server & client都有類似的設定流程，平常這些logging都是關閉的，需要先手動去開啟

   server:
   1. Open Event Viewer (eventvwr).
   2. Browse to Windows Logs\
   Applications and Services Logs\Microsoft\Windows\Deployment-Services-Diagnostics.
   3. Right-click the channel and choose Enable Log.
   
   client:
   WDSUTIL /Set-Server /WDSClientLogging /Enabled:Yes
   

   而且也都有logging level的設計針對不同的debug情境

   server:
   wdsutil /verbose /Get-Server /Server:MyWDSServer /Show:All /detailed
   wdsutil /Verbose /progress /Delete-AutoAddDevices 
   /Server:MyWDSServer /DeviceType:ApprovedDevices
   
   client:
   WDSUTIL /Set-Server /WDSClientLogging /LoggingLevel:{None|Errors|Warnings|Info}
   

   同時，文章裡頭也不忘要提醒使用者，使用這些除錯功能要留意效能的影響，另外還有一個被大家常常忽略的是長時間的除錯導致硬碟空間的耗盡。

   Note:
   A tracing process may affect performance. Therefore, we recommend that you disable the tracing functionality when you do not have to generate a log.
   

2. 硬體錯誤：

   硬體的錯誤，通常會透過其對應的driver，將錯誤反應於OS的syslog之中，主機有自帶BMC功能的，也可以同時查找BMC的log，看能否鎖定有沒有可疑的硬體導致錯誤的發生。

   有時相關聯的硬體之間，也可以透過廠商的工具來dump詳細的device firmware log，像是硬碟錯誤時，除了使用硬碟廠商的工具來檢查，也可以檢查raid controller的firmware log，看有沒有記錄到詳細的時間和原因。畢竟硬體的錯誤有時是裝置間互相通訊時發生的，通訊的發送端或是接收端都有機會成為回報硬體錯誤的源頭。

   如果遇到無法明顯從log裡看出問題的情況，這時候可能就要動用信號/協定分析的機器了。

   最後甚至可以針對有疑慮的硬體，請廠商提供debug firmware來做更有效率的除錯。

3. 韌體錯誤：

   韌體錯誤和硬體錯誤收集log的手段其實很相似，因為這年頭大多數的硬體錯誤有時來自於上頭執行的韌體有bug，又或者是用韌體更新的方式來修正或是緩解硬體錯誤帶來的傷害。有時這一類的錯誤，可以從Serial console port中看到更多的詳細錯誤資料，因此當機器開機過程中有不尋常的長時間等待時，也可以考慮檢查下serial console port中是不是有更多的訊息可以查看。